Component Reliability Extensions for Fractal component model

Fractal is a component model developed initially by France Telecom and INRIA and later as an open source project in the ObjectWeb consortium. The component model is defined by the Fractal Component Model specification [BCS]. The specification defines a hierarchical component model, where a component is specified in terms of its server and client (provided and required) interfaces and configurable attributes. The model supports advanced features such as component sharing, mandatory/optional interfaces , collection interfaces. The Fractal API is defined for three languages: Java, C, and CORBA IDL. The reference implementation of Fractal, Julia, is developed in Java and supports Java Fractal components. The Fractal specification allows to use an Architecture Description Language (ADL), however, it does not directly specify one. In the Fractal ADL project, an XML-based ADL for the Fractal component model is defined to specify the initial architecture of an application. The features of this ADL language include inheritance among component specifications, and also a mechanism to specify values of components' attributes. The Fractal component model specification is very flexible (and structured in several conformance levels), consequently, many concrete component systems comply with it. To make the integration of behavior protocols into Fractal possible, we take the following additional assumptions: (1) In Fractal, every component has internal and external interfaces. We suppose that for every external interface there exists an internal interface of the same type (and vice versa). In addition, an event on an external interface immediately causes the complementary event on the corresponding internal interface , and these two events happen atomically. In a similar way, an event on an internal interface immediately causes the complementary event on the corresponding external interface (and the two events happen atomically). (2) Interfaces in Fractal are connected by bindings. We suppose that an event occurring on an interface I causes immediately the complementary event on the interface I is bound to, and the two events happen atomically, assuming I is bound to exactly one interface. If I is bound to more interfaces, the events on those interfaces do not have to happen atomically. The purpose of behavior protocols is to specify the behavior of software components, so that interesting properties of their behavior can be verified. The problem of behavior verification is undecidable in general. There are two ways to face it: (1) To use behavior description languages which describe behavior of the software precisely and to put …